When the number of subscribers for a specific service in a communications network increases, load balancing becomes a crucial issue. Here, an increasing number of tasks have to be spread as effective as possible between network devices provided in a limited number in a communications network and configured to perform the corresponding tasks.
Application servers can handle a predetermined maximum amount of users. However, this predetermined maximum amount of users is less than the number of subscribers, to which a communications network can provide access in general. When considering public land mobile networks (PLMN), for example, a PLMN operator owns gateway support nodes like Gateway GPRS Support Nodes (GGSNs), which represent interfaces between external networks and the PLMN and which are capable of serving thousands or millions of subscribers. These gateway support nodes are interfaces to application servers and provide services to the subscribers by using connections to the application servers. However, on the other hand, application servers (e.g., WAP (Wireless Application Protocol) gateways, MMS (Multimedia Messaging Service) servers etc.) can not handle requests coming from such a large amount of subscribers.
Thus, load balancing mechanisms are necessary to avoid service outages. Even in cases, where clustering or other internal server load balancing mechanisms are deployed, those mechanisms are not sufficient for handling of the steadily increasing load.
When considering PLMNs, a mobile subscriber or mobile node, respectively, activates packet data protocol (PDP) contexts toward gateway network elements, which are configured to provide access to other networks such as internet, corporate networks or services of the operator, for example. Such a gateway network element can be, for example, a legacy GGSN as defined by the 3rd Generation Partnership Project or an intelligent node with service awareness/switching capabilities such as the Flexi Intelligent Service Node (ISN), for example.
A gateway network element provides access to Packet Data Networks (PDNs). The GGSN is selected by an Access Point Name (APN), which is provided either by the subscriber itself (e.g., it is configured explicitly in the equipment of a mobile node) or by a Home Location Register (HLR). In FIG. 1 the activation of a PDP context as mentioned above is shown exemplary. In FIG. 1, a subscriber or mobile node 10, respectively, transmits a PDP context activation request 13 through its access and core network 11 to a GGSN 12. The GGSN 12 responsible for providing access to PDNs and identified by APN creates a PDP context response message and transmits this message 14 to the mobile node 10.
As regards load balancing of GGSNs, the load balancing can be achieved, for example, by use of external routers or other network elements, which act as “load balancers”.
If several GGSN nodes are provided, it is possible that the same APN is served by several GGSN nodes. In such cases, the Serving GPRS Support Node (SGSN) will make a load balancing decision when it selects a GGSN. However, for application server load balancing, this approach is not sufficient, as a single GGSN node can still generate too much load for application servers and as GGSNs have higher capacity than server nodes providing applications.
Further, existing Gi load balancing solutions are not flexible enough. They usually involve presence of new network elements, which, in turn, increase OPEX and CAPEX. Thus, an integrated solution offered by a gateway node like GGSN of the PLMN is necessary.
One of existing prior art solutions exploits features of Flexi ISNs, in particular, of the GRE tunnelling feature. Here, the Flexi ISN can be connected to external servers using up to two GRE tunnels, which can be redundant. The Flexi ISN uses both tunnels (the normal and the redundant tunnel) actively. Here, when a new PDP context is activated, the tunnel having the least load is used. The load of a GRE tunnel is defined by a number of PDP contexts, which use the corresponding GRE tunnel. An operator can use the redundant tunnels for load balancing by connecting each of them to a separate application server. This solution of prior art is visualised by FIG. 2. In FIG. 2, a SGSN 20 selects a Flexi ISN 21 and transmits a PDP context activation request to the Flexi ISN 21. The AP 210 comprised in Flexi ISN 21 provides connections to application servers 24_1 and 24_1 by corresponding GRE tunnels 22_1 and 22_2, wherein the messages transmitted to the WAP servers 24_1 and 24_1 have to pass the corresponding firewalls 23_1 and 23_2. After activation of a PDP context the AP 210 and, thus, the Flexi ISN 21 uses the least loaded GRE tunnel 22_1, 22_2 to provide services to the corresponding subscriber or mobile node, respectively.
However, when this solution is successful for load balancing for two external application servers, problems arise when a load balancing for more than two servers is required. Further, also cases are possible, in which a GRE tunnelling is not wanted or preferred.
Moreover, also other problems can arise with regard to the above described solution of prior art. The Gi interface, being an interface between the Flexi ISN and the PDN and defended by 3GPP, groups a variety of dependent functions together and the load balancing method has to consider these dependencies. Thus, for example, a RADIUS (Remote Authentication Dial In User Service) accounting protocol is used to inform a WAP server about the status of PDP contexts. Here, the load balancing mechanism has additionally to be able to select the right RADIUS accounting server when the GRE tunnel is selected.